Imperative programming is a computer programming paradigm that describes computation as a series of statements that change a program state. Imperative programming can be contrasted with functional programming, which avoids state and mutable data. For example, purely functional programs have no side effects, which are modifications of some state while returning a value. On the other hand, a purely functional program can do nothing because without side effects a program accepts no input, produces no output, and does not interface with external devices. Imperative programming uses side effects to implement state and input/output functions. Accordingly, many programmers and software development engineers are most familiar with imperative programming and often these programmers take for granted that data structures change over time.
Mutability was less of a concern in programming for single processor architectures. Mutability is a challenge, however, in the now ubiquitous concurrent (such as multiprocessor or parallel) processing architectures. Adding immutability to existing imperative, or mutability-oriented, programming languages such as C++, C#, Visual Basic, and Java, can simplify imperative programming in concurrent architectures. A major difficulty in building concurrent systems today is related to how an imperative system approaches ever-changing states.
Many programmers attempt to address the issue of mutability through the creation of “locks” of the state, and synchronization to control concurrent reads and writes of states. Locks are used on an object when the program only desires to inspect a state to avoid changing the state during inspection. Locks and synchronization lead to recursive lock acquisitions, deadlocks, additional overhead, and other undesireable affects. Further, locks and synchronization can create related problems such as races.